1. Field of the Invention
This invention relates in general to graphical input devices and in particular to input devices in which users select from a list of choices.
2. Description of the Related Art
Sending and receiving information via networks, especially the Internet, has become a daily event for a large number of people throughout the industrialized world. Airline tickets are ordered, books are bought, reports are submitted, subscriptions are entered, and thousands of other tasks are now routinely completed on-line.
Although the hardware devices—servers, routers, cables, etc.—that make the Internet possible are of course indispensable, they are transparent to most users. What is by definition very obvious to users, however, is the interface between them and the hardware structure. In the context of on-line information exchange, the most important components of this interface are the graphical user interface (GUI) of the user's computer in general, and the browser in particular.
FIG. 1 illustrates the well known, general components of a typical computer: System hardware 100 includes one or more processors (CPUs) 110 and one or more volatile and non-volatile memory devices 112. The system hardware will typically also include I/O cards and controllers 114 as needed to communicate with and control such input devices as a mouse (or trackball, joystick, etc.) 120 and keyboard (or speech recognizer, etc.) 122, as well as output devices such as a display monitor 124, which display screen 126 is viewed by the user.
System software 200 is usually installed to run on the hardware “layer” 100 and will include an operating system (OS) 220 and various drivers 222 that are used for software control of physical devices; note that the drivers 222 are typically installed in the OS itself. The GUI 224 is also often an integral component of the OS. One of the features of a GUI is that, together with supporting hardware components, it senses the position of an on-screen indicator such as a cursor 230 and relates this position to other displayed graphical devices such as icons, scroll bars, data entry fields, etc. When a user positions the cursor over a data entry field and causes some predefined activating event, such as “clicking” an appropriate button of the mouse 120, the GUI may, for example, associate text entered via the keyboard 122 with the variable or parameter width to which the selected data entry field is associated.
A user-level software layer 300, that is, applications, are usually installed to run on the system software. There are of course countless applications and it is these programs whose operation is most visible to users. In the context of the Internet, the application most relevant is known as a browser 310. At present, the most widely used browser is Microsoft Internet Explorer, of which there are several versions.
Defined broadly, a browser is an application that interprets and arranges elements (text, sound images, etc.) on a displayed web page so that a user can see and interact with network content. Defined a bit more specifically, a browser is software that interprets the programming language of the Internet into the text, graphics, sounds and effects (such as blinking, scrolling, etc.) that one sees when viewing a web page.
The programming language that all widely used browsers interpret is the Hypertext Markup Language (HTML), as well as its various derivatives such as DTML, XML, DHTML, etc. HTML is standardized by the World Wide Web Consortium (W3c) and is followed by most of the leading browsers. HTML is structured as a series of elements (commonly known as “tags”), each of which contains an instruction commanding the browser how to display, for example, images and words. Different versions of HTML support not only text, multimedia, and hyperlink features but also scripting languages. When a user, via the browser 310, contacts a web site (for example, using a URL) and requests download of content, what is transferred over the network 700 from the site-hosting server 800 is the HTML code and data, which the browser then interprets to generate the display that the user actually sees.
A “script” is a list of commands that are embedded in the HTML code defining a web page and can be executed by or within the browser. In essence, a script is a “program within a program” and can be used to affect the actions of the browser. The scripting language most commonly used in the Microsoft Internet Explorer, for example, is “Visual Basic Scripting Edition” or “VBScript” for short. VBScript is a simplified derivative of the Visual Basic programming language and enables web authors to control the action and visual characteristics of interactive controls. The time and nature of the execution of the script is controlled by the script designer and can be called from within a web document. The script is often activated and run as a result of mouse functions, buttons, or other user actions.
All of the hardware and software features and concepts described above are very common and well known. What is also common, but less noticed by users, is that conventional graphical, text-input devices generated by browsers have limited flexibility. In particular, because of the nature of existing HTML tags, the width of the displayed input field of a device such as a “pull-down menu” or “selection box” is determined by the widest possible entry, or a predefined width set by the programmer. This limitation is illustrated in FIG. 1, which shows a very simple example of a web page, with a logo 400 and data entry fields for a customer number, the date, and a state/province. This might for example be the input screen for a company that wants tracking information for all shipments of goods to a given state/province on a certain date for a given customer.
Where there are a large number of different customers, it would be impractical for the browser to display every possible customer number. Assume therefore for the sake of this example that the user has obtained the customer number before entering the illustrated input screen; for example, he may have looked up the number using a previously displayed web page. To enter the customer number the user positions the cursor 230 to point within a corresponding data entry field 410, clicks on a mouse button to select or “activate” this field, and, using the keyboard 122, enters the desired customer number. By pressing the “Enter” key on the keyboard, by double-clicking the mouse button, by clicking the mouse button outside the data field 410, and/or by taking any similar field predefined action, the user indicates that he has completed his entry for the customer number. The browser then associates the entry with the corresponding parameter, which is defined as part of the HTML code. This is the operation of a standard HTML <INPUT> element.
The user may enter the date similarly, for example, selecting the Date data field 420 and typing in a date. Alternatively, it is common to display a small calendar icon 422 next to a date input field. When the user clicks on this icon, some portion of a calendar is displayed and the user can select a desired date by “clicking” on its portion of the displayed calendar. Assuming a monthly calendar is displayed, then each day would be a data selection field of its own, although no input is permitted other than selecting it with, for example, a mouse click or keyboard indication such as “Enter.” Once a date is selected or typed in, then it is similarly associated with the corresponding HTML parameter.
The example shown in FIG. 1 also includes input fields 420, 424 and buttons 422, 426 for the customer's country and state/province, respectively. Consider now the State/Province data entry field 430. In the illustrated case, the user is to select this entry using a class of display devices known as a drop-down select list. Here, when the browser detects that the user has selected the data field, or an associated activating button 432, the browser displays a drop-down list 434 of possible choices. This list is displayed just below the data entry field 430; although this is done to make the selection more intuitive; it is also a requirement of the HTML <SELECT> element.
Assume now that the possible country entries are the USA, Canada 13, Germany 16, Switzerland 26 or Sweden 21, which are further divided into their respective states, provinces/territories, Bundesländer, cantons and Iän. In other words, there are (as of 2002), 50+13+16+26+21=126 choices the user might make. The question then becomes: How many characters wide should the data field 430 be displayed? The answer in all conventional browsers is: At least as many characters wide as the number of characters in the largest possible entry. In this example, this would mean that the data entry field 430, as well as the drop-down list 434, would need to be at least 22 characters wide in order to accommodate the possibility that someone would need to enter the German state of Mecklenburg-Vorpommern or the Swiss canton of Appenzell Ausserrhoden. This would be so even though the widest entries for the USA, Canada or Sweden would be only 14, 21, and 15 characters wide, respectively, in order to accommodate North or South Carolina, Northwest Territories, and Västra Götaland.
This limitation has at least one significant drawback, the common solution to which creates different drawbacks of its own: As FIG. 1 illustrates, although the left edges of the data entry fields 410, 420, 424, and 430 are aligned, the right edges usually will not be, unless all of these fields are wastefully made 22 characters wide as well. Misalignment of displayed input fields is not always merely a cosmetic disadvantage, although this disadvantage may in fact be significant enough on web pages that need to appear professional and be easy to use: If the page designer wishes to include many more displayed elements on the displayed page, for example, there may not be enough space without reducing font sizes below a legible minimum. In short, the inflexibility of existing browser-based, multiple-choice graphical input devices such as pull-down menus reduces the layout freedom of the web page designer.
One common attempt to avoid the drawbacks of an overly wide input field is to require the user to select from a list of abbreviations. In many cases, there are no standardized, widely recognized abbreviations, in which case users must be forced to learn them or look them up. This is of course often inconvenient. Even where there are standardized abbreviations, however, this solution is not necessarily easy to use since it still presupposes that all users know them. Continuing with the example shown in FIG. 1 and described above, it would be possible to list only the standard two-letter abbreviations for the possible states, provinces, etc., and countries. Not all European users would know off hand, however, that Mississippi and Missouri are abbreviated MS and MO, although this is arguably more likely than that the average American user would know that Sweden and Spain are abbreviated SE and ES, respectively.
The example shown in FIG. 1 is a mild illustration of the problem. One actual web site run by a major U.S. airline for on-line reservations had a “State” field for the user's address. In addition to the expected 50 entries, for which a field width of 14 characters would suffice, there was also a choice “Armed Forces Americas (except Canada)”. The corresponding data entry field was therefore 37 characters wide (in fact, more, presumably to leave open the possibility of even longer possible entries), although the number of users requiring the long, 37-character entry is almost certainly miniscule compared to the number of users from the more compactly named States Iowa, Ohio, and Utah.
Another known method of reducing the necessary width of a data input field is for the possible entries to be truncated. This solution presents problems similar to those associated with abbreviations, including the drawback that an essential part of the information to be displayed may not be displayed at all.
The limitations of existing pull-down menus arise from the definitions of the HTML (for example) code with which they are created. Typically, a drop-down list is created in HTML using a <SELECT> element, which is an element that defines a set of options associated with an HTML label. Although the browser typically generates the drop-down menu and its other associated display fields (such as the button and selection box) when the page loads, it keeps these display objects invisible until the appropriate time. For example, if a user has scrolled down so far on the display screen that the menu should not be visible, then the browser ensures that it is not. The menu, its associated selection box, and the (optional) button may be made invisible or visible independently.
Associated with each input field, including those associated with <SELECT> elements, are predefined “focus events,” which are user actions that indicate to the browser that the user wishes to enter data into that field or make a selection via the list. Typical focus events include the user “clicking” on the displayed data entry field, tabbing into the field, and/or clicking on a button next to the field. When an event handler within the browser senses a focus event associated with a drop-down menu, the browser will turn on the visibility of the corresponding selection box and position it correctly, normally just under the data entry field that is to be “filled in.”
The possible selections for a pull-down menu may be determined in different ways. Note that a selection box can be considered as an array, with each row containing one possible value. There are different ways in which to populate this array with possible values. In the simplest case, all selections are included directly in the definition of the <SELECT> element and are transferred to the browser along with other HTML code used to generate the current web page. Another possibility is that the browser, upon encountering the <SELECT> element, contacts the server sending the page and downloads the possible selections, which are then stored in the array. In either case, existing browsers set the width of the data entry field of the <SELECT> element to at least the width needed to fully display the widest selection in the array; this width may also be fixed by the programmer.
One illustration of this technique is found in web sites developed by the EXportFILE company of Reno, Nev. In the pages displayed using EXportFILE technology, a drop-down menu may be wider than the input field with which it is associated. This allows users to see all possible entries full-width while not requiring the displayed data entry field itself to be set at the maximum width. The main drawback of the EXportFILE solution, however, is that the maximum width of the drop-down selection list is predetermined in the definition of the corresponding <SELECT> element, and is the same for all users. In other words, the width of the drop-down selection list, as well as all possible selections, are set and are included in the HTML code first transferred into the browser, regardless of the user. If one user has a single, very wide possible entry in a selection list, then the selection list displayed for all users will be wide enough to accommodate the one user's one wide entry. Although the selection list will disappear from the display as soon as a selection is made or is otherwise inactivated, it would still be advantageous not to display selection list any wider than necessary in order to obscure as little of the rest of the display as possible.
The EXportFILE solution may be adequate in cases where all users are to be presented with the same choices in each selection box. This is not always so, however. One example of a situation in which the one-size-fits-all approach does not work well would be where a company's employees go to customer sites for different reasons but all submit trip reports via the Internet. The reasons that a technician might go to the site will probably be very different from the reasons that a sales representative would visit. A contract employee placed at the customer's site would have still different tasks to report back. If the on-screen reporting form includes an input field such as a task code, then the possible codes would be very different for the different reporters. Moreover, the list of possibilities may change with time. Ideally, the choices presented to users could be easily updated and would correspond to the type of services each performs; this is not possible where the HTML code controls the input.
It is also possible to condition the width of one selection list on an entry into a different input field. Returning to the example of FIG. 1, if a user enters “USA” as the country, the browser could automatically restrict the drop-down selection list to U.S. states, so that a selection list 14 characters wide would suffice. Using existing browser technology, this is, however, practical only where the possible selections are known in advance and can be included in the definition of the corresponding <SELECT> element.
There are usually two different ways to navigate through the list of choices in a drop-down menu. Especially where only a portion of the total number of choices is displayed in the drop-down field at any one time, the first is to use the mouse (or equivalent) and cursor to move a scroll bar 436 until the desired entry becomes visible, and then select it in the normal manner. Another method, which may be combined with the first, is by using so-called “key press events.” As its name implies, these events are triggered by the user performing some action on the keyboard, which the browser then converts into an appropriate action for the menu. For example, if a user presses the “Up” or “Down” arrow key when the selection box is active, the browser will highlight the entry just above or below the previous selection, respectively, and may scroll the display as needed, for example, where there are more possible choices than can fit in the displayed selection box. Pressing the “Enter” key or double-clicking with a mouse, however, is usually interpreted as meaning that the user has selected the currently highlighted array element for entry into the data field; the browser then typically once again renders the selection box invisible.
Another common and convenient type of key press event is where the user presses one of the alphanumeric and/or symbolic keys of the keyboard, for example, in order to input the first character of the desired selection. The browser then automatically scrolls to the first selection beginning with that character. For example, if the user wishes to select “Maryland” from a drop-down list of states, then he can type “M.” Assuming that the entries are ordered alphabetically, the browser will scroll the drop-down selection box to the entry for “Maine,” which it will typically also highlight. “Maryland” will then be visible as the next entry and can be selected with the mouse as usual, or by pressing the “Down” key followed by the “Enter” key.
The problem with existing graphical input devices is that they do not make it convenient and intuitive to go to the “Maryland” selection directly using the alphanumeric or symbolic keys alone: In many browser-based environments, if the user were to type “M” and then “A”, the browser would first scroll to and highlight “Maine,” but then would immediately scroll back up to the top of the list and highlight “Alabama,” leaving the user no better off than when he started.
In some other browser environments, selections are grouped according to first characters and users can cycle through each group by repeatedly entering this first character. Continuing with the example above, the first time the user enters “M,” “Maine” is highlighted, since it's the first state in alphabetical order that begins with the letter “M.” Repeatedly entering “M” causes the browser to highlight, in turn, Maryland, Massachusetts, Michigan, Minnesota, Mississippi, Missouri, and Montana, whereupon it returns to highlighting Maine. In order to select “Montana” using the keyboard alone, the user would therefore have to enter “MMMMMMMM”; “MMMMMMM” would not be enough “Ms” and “MMMMMMMMM” would be too many. In other words, the user would need more keystrokes (eight “Ms”) to select Montana than if he had simply typed the entire name “Montana” (seven keystrokes). This is both inefficient and non-intuitive.
The problem of inefficient and non-intuitive selection of entries from a drop-down list is compounded where the entries are ordered as items, sub-items, sub-sub-items, and so on, that is, hierarchically. For example, assume that a list is to include the various job functions in a large corporation. An alphabetically ordered list would in most cases be impractical. Rather, it would in most cases be better to organize the job functions by division, group, department, task, etc. For example, the administrative assistant in the patent department might be classified as “Corporate:Legal:Intellectual_Property:Patent:Admin_Assistant.” Obviously, using any of the prior art selection methods described above would be far too cumbersome.
What is needed is therefore a graphical input device similar to a selection list that eliminates the need to size displayed entry fields to the largest possible entry, while still allowing the user to see full-width, complete selections. The width of the selection list itself should be flexible and not require all users to view a list dimensioned to accommodate the widest possible entry of any user. Preferably, the input device would also allow for easier direct keyboard selection of listed items, even where the items are arranged hierarchically. This invention provides an input device that has either, or both of these advantageous features.